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E-commerce, in terms of the monetary value 
of transactions, is heavily skewed toward 
business-to-business (B2B) commerce. 
Numerous B2B sites are already in existence, 
providing a fairly rich set of functionality for 
enabling simple or sophisticated trading of 
goods and services. In the coming years, we 
expect a strong growth in many kinds of B2B 
sites for trading, procurement, and sales. In 
this paper, we present a B2B platform 
suitable for various kinds of businesses such 
as large sellers, dealers, distributors, private 
exchanges, marketplaces, and procurement 
hubs. We present business scenarios, 
describe our design criteria, and present the 
architecture for the B2B platform. We discuss 
two major IBM offerings within the 
WebSphere® Commerce Suite product— 
WebSphere Commerce Suite, Marketplace 
Edition (MPE) and WebSphere Commerce 
Business Edition (BE)—that are based on this 
platform. We also present some experiences 
with and deployment of MPE for private 
exchanges and marketplaces. 


Over the last few years, a tremendous number of in¬ 
formation sites have emerged on the Internet, pro¬ 
viding a variety of content, commerce, and collab¬ 
oration services to individuals, businesses, social 
communities, and nonprofit organizations. Recently, 
driven by new business models, new kinds of com¬ 
merce sites (e.g., private exchanges, e-marketplaces, 
and portals) have emerged on the Internet. These 
sites have many similarities to physical commercial 


by J. Sairamesh 
R. Mohan 
M. Kumar 
L. Hasson 
C. Bender 

marketplaces and financial markets, except that the 
boundaries are not restricted by physical space or 
proximity. Instead, the boundary limits are defined 
by the costs of participation, search and transaction 
overheads, integration overheads, computational re¬ 
sources, and other frictional issues. In spite of the 
overheads, the popularity of business-to-business 
(B2B) technologies is growing at a steady pace, and 
these technologies are being embraced by new and 
mature companies for efficiency in business trans¬ 
actions. The evidence is clear; companies completed 
more than $433 billion 1 of B2B commerce transac¬ 
tions on line (since launch) in the year 2000, and 
transactions are expected to have reached $900 bil¬ 
lion in the year 2001. 

We are currently witnessing a trend in the forma¬ 
tion of medium- and large-scale B2B commerce sites 
providing services to diverse businesses over the In¬ 
ternet. Some of these sites are evolving from infor¬ 
mation portals to offering more complex commerce 
and collaborative environments in order to enable 
businesses to trade goods and services efficiently. 2-5 
We are also witnessing an era of business transac¬ 
tions extending from the Internet into the intranets 
of businesses and connecting together the back-end 
“workhorses” such as enterprise resource planning 
(erp) systems, logistics servers, and supply-chain sys¬ 
tems, thereby improving the efficiency of order-cap¬ 
ture, management, and fulfillment, resulting in im- 
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proved production on the sell-side (sites for selling) 
and improved efficiency of purchasing on the buy- 
side (sites for buying). 

In the next section we present some of the emerging 
business models for B2B commerce, which are the 
following: sell-side Web sites that promote sales over 
the Internet, procurement sites to enable low-cost 
purchasing for buyers, e-marketplaces that bring 
multiple buyers and sellers together for trading, and 
marketplaces that are owned privately (e.g., distrib¬ 
utors, resellers, and seller consortia), where partic¬ 
ipation is limited to a few select buyers and sellers. 
We then discuss the architecture of our platform for 
B2B transactions targeted toward private exchanges, 
distributors, and large sellers. In the fourth section 
we discuss two IBM software offerings that serve as 
B2B platforms. One of them, WebSphere* Com¬ 
merce Suite, Marketplace Edition (mpe), is targeted 
toward private exchanges and public marketplaces 
and is partly for distributors and brokers, whereas 
WebSphere Commerce Business Edition (be), is tar¬ 
geted toward sellers who sell to other businesses. In 
this section, we also present some of the experiences 
gathered in deploying MPE. We conclude the paper 
with a summary. 

B2B models and business scenarios 

Our goal in designing and implementing the B2B plat¬ 
form was to support a wide variety of B2B business 
processes. Toward this goal, some of the underlying 
questions we addressed were the following: What are 
the core components to enable B2B transactions in 
various business and industrial scenarios? What are 
the relevant trading mechanisms? What are the ac¬ 
cess policies for private exchanges? What are the core 
business process flows? What are the required in¬ 
tegration issues with business processes at the sup¬ 
plier or buyer back-end systems? In this section, we 
present some B2B business models and also describe 
some of the most common business scenarios em¬ 
ployed by the B2B Web sites. 

In recent years, public B2B e-marketplaces gained 
some popularity by allowing any business to register 
for a low fee and trade almost immediately. These 
sites initially were attractive to participants because 
they aggregated buyers and suppliers, reduced search 
costs, and promoted price discovery. 2 However, they 
face many challenges to generate revenue and sur¬ 
vive. First, such marketplaces need a viable strategy 
to attract and sustain buyers and sellers at the mar¬ 
ketplace. Since many of these buyers and sellers al¬ 


ready have existing relationships, adding additional 
value that generates more revenue in the market¬ 
place is challenging. Second, suppliers may risk their 
business by being exposed to more competition in 
a public marketplace where buyers could negotiate 
better delivery dates, payment terms, credit terms, 
and discounts on goods before purchasing. Suppli¬ 
ers may want to differentiate their products, whereas 
market makers want to describe products across sup¬ 
pliers in a common fashion to enable a better search 
and comparison. These compelling reasons and con¬ 
flicts of interest caused most of these public mar¬ 
ketplaces to become unattractive over time. 

Very recently, market makers who have understood 
the industry structure have evolved to provide pri¬ 
vate marketplaces 6 on the Internet that capture ex¬ 
isting relationships among the buyers and sellers. Pri¬ 
vate marketplaces are attractive to suppliers because 
they protect their relationships with buyers. Business 
relationships in the form of contracts can be estab¬ 
lished between sellers and buyers at these private 
sites, and trading can be done based on those rela¬ 
tionships. Some of these private marketplaces are 
owned by a buyer consortium in order to pool pro¬ 
curement functions or out-source procurement to 
an independent company. 7 This creates greater buy¬ 
ing power. Suppliers not willing to participate may 
be shut out of the market. To add value and bring 
in liquidity, private marketplaces based on an indus¬ 
try organized vertically can provide valuable infor¬ 
mation about the industry. 3 In addition, the market¬ 
place can provide better efficiencies and savings 
through Web-based deal-making for businesses. The 
marketplace can also act as a portal for communi¬ 
cation between members of the industry. 

Private trading exchanges are typically owned by 
large selling or buying organizations or by a consor¬ 
tium of buyers or sellers, by a reseller, or by a dis¬ 
tributor. The company that owns a private exchange 
may have many suborganizations, each acting as its 
own purchasing agent. These individual buying or¬ 
ganizations within the larger company may be deal¬ 
ing with many suppliers, sometimes the same sup¬ 
pliers. Private trading exchanges provide a one-stop 
shop for suborganizations within a company to pool 
their requirements and present an aggregated order 
to the suppliers, thereby increasing the purchasing 
power to negotiate for better terms and conditions. 
Again, this setup is favorable to the buying company 
but not for the suppliers. Other incentives need to 
be added to attract suppliers. If the company run¬ 
ning the private exchange has enough market power, 
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Figure 1 Private exchange models 
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it can force the suppliers to participate. Otherwise 
a supplier may lose too much business. As an incen¬ 
tive to participate, some private exchanges have of¬ 
fered suppliers services, such as the ability to auc¬ 
tion excess inventory on the site to other companies. 

In Figure 1, we illustrate two models of private ex¬ 
changes. In the buy-side private exchange, a buying 
consortium owns the exchange mainly for procure¬ 
ment functions. In a sell-side private exchange, the 
selling consortium owns the private exchange for 
sales. Both require a platform to support multiple 
buyers or multiple sellers, or both, and various forms 
of trading mechanisms such as requests for quotes 
(RFQs), contract negotiation, contract-based buying, 
catalog-based fixed-price 8 buying, and auctions. 

In a buy-side private exchange, the buyer can pur¬ 
chase through the catalog based on fixed prices, 
through an established contract on specific products, 
or through an RFQ-based negotiation process for one 
or more product items. For fixed-price purchasing, 
the buyer browses an aggregated catalog at the pri¬ 
vate exchange Web site. The buyer adds items to an 
interest list for current and future repeat purchas¬ 
ing. Once this is done, the buyer places an order and 


specifies the preferred shipping information. The or¬ 
der is sent to the private exchange Web site for pro¬ 
cessing, which captures the order, 9 and routes it to 
the proper set of suppliers by disaggregating (split¬ 
ting) the order. 

In a sell-side private exchange, one or more sellers 
own and manage the marketplace. The sellers wish 
to use this exchange as a sales channel for primary 
and secondary goods. The exchange maintains an ag¬ 
gregated seller catalog and a collection of contracts 
between sellers and buyers. The sellers can sell their 
inventory via contracts, through fixed-price sales, or 
via auctions for sales of surplus goods. The trend re¬ 
cently has been toward large sellers and distributors, 
who manage a large 10 catalog of products and wish 
to be connected to third-party supplier systems for 
quick order fulfillment. 

Figure 2 illustrates a distributor model, where the 
Web site provides buyers with advanced purchasing 
capabilities. The distributor Web site connects to 
manufacturers and suppliers so that orders can be 
sent automatically to them for replenishment when¬ 
ever inventory runs out. The buyer is able to see the 
distributor’s price and available quantity informa- 
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Figure 2 Distributor business model or sell-side businesses 
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tion on products. In this model, buyers cannot trans¬ 
act 11 business directly with the manufacturers and 
suppliers. All orders go through the distributor and 
are processed manually or automatically. Distribu¬ 
tors typically negotiate with manufacturers for bet¬ 
ter price discounts based on relationships and offer 
incentives for buyers to purchase through them. They 
also handle invoicing and logistics, which helps in 
reducing costs for the buyers. 

Architecture 

In this section, we provide a summary of the design 
criteria for building a B2B platform for marketplaces, 
private exchanges, and sell-side distributors. 

Design criteria. There are many design criteria to 
consider when creating, developing, and deploying 
a B2B site. Some of the core criteria are as follows: 

• Capturing member profiles and representing peo¬ 
ple and their roles in businesses are crucial require¬ 
ments for B2B transactions. 

• Catalog aggregation across multiple suppliers for 
private exchange and distributor models of com¬ 
merce are necessary to provide one-stop shopping. 


• Access control on the catalog and price informa¬ 
tion is required to limit what a buyer or a seller 
(or a person with a role) can do or view in the sys¬ 
tem. Access control plays a very important role in 
private exchanges. Access control on information 
and trading is crucial to allow only certain mem¬ 
bers to trade. 

• Search on catalog: Search of product descriptions 
and product offerings that contain many attributes 
is complex. The search criteria include, among oth¬ 
ers, product identification (id), many product at¬ 
tributes, and supplier ID. 12 A good parametric 
search engine, which empowers the buyers to 
quickly narrow the search to products of interest, 
is crucial for the success of the B2B site. 

• Framework for trading: A platform for support¬ 
ing private and public exchanges needs a flexible 
framework to instantiate auctions, reverse auc¬ 
tions, exchanges, and RFQs, and to enable multi¬ 
attribute, multiround, and multistage negotiations. 

• Order aggregation, order splitting, and order con¬ 
firmation: Orders can be aggregated across mul¬ 
tiple buyers, and the distributor can negotiate ad¬ 
ditional discounts for the buyers. Orders placed 
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Figure 3 Platform architecture for B2B private exchanges and sell-side sites 
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by buyers should contain items from one or more 
suppliers, and an order needs to be split among 
the suppliers. Similarly, responses have to be gath¬ 
ered from the suppliers and order confirmations 
sent to the buyers. 

• Scalability: The issues of scalability are many. For 
example, the typical catalog sizes can be 1-50 mil¬ 
lion products in a large private exchange. Each 
product can have an average of 20 attributes, and 
the search on such a catalog needs to scale with 
the growing catalog size. Components such as auc¬ 
tions, RFQs, and orders should scale with the num¬ 
ber of hardware nodes. 

• Mobile e-business: With mobile commerce evolv¬ 
ing at a rapid pace, 13 some of the participants will 
use more than one device (including a Web 
browser) to access information from the commerce 
site and receive notifications on business transac¬ 
tions. For example, devices such as personal dig¬ 
ital assistants (PDAs) and pocket PCs are inexpen¬ 
sive and computationally powerful. 14 Support for 
these devices is of tremendous value for sales and 
purchasing people who are mobile and need the 
flexibility to handle simple business transactions 


and notifications such as order confirmations, or¬ 
der cancellations, and order statuses. 

• Evaluation mechanisms and intelligence: Algo¬ 
rithms for bid evaluation and bid-ranking must be 
provided to help the buyer select among complex, 
combinatorial bids in multiattribute, multi-item 
RFQs, reverse auctions, and exchanges. Pricing al¬ 
gorithms play a very important role in B2B con¬ 
tracts, auctions, and double auctions. Reporting 
functionality is a crucial requirement for gather¬ 
ing intelligence, decision-making, negotiating new 
contracts, and evaluating past transactions. 

• Integration to back-end systems such as ERP, lo¬ 
gistics, inventory, and pricing servers: The require¬ 
ments apply to sell-side and buy-side private ex¬ 
changes, where orders are exported from the 
exchange to the supplier back end. 

Architecture components. The architecture, shown 
in Figure 3, illustrates the various components in the 
platform. The platform shows the core middleware 
commerce components, on top of which are the var¬ 
ious commerce application components for B2B 
transactions. In this subsection, we describe some 
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of the components that are crucial to enabling trans¬ 
actions in B2B sites. 

Membership. The success of any B2B site depends on 
how well it captures the structure and representa¬ 
tion of businesses and the roles of people in the bus¬ 
inesses involved in sales, purchasing, or approval. 
Representing roles of participating B2B organizations 
(buyers, sellers, administrators, and regulators) is a 
crucial requirement. Membership information is typ¬ 
ically used for access control, ownership of docu¬ 
ments and information created at the Web site, credit 
verification, order placement, approvals on pur¬ 
chases made by the buying organization, shipping in¬ 
formation, and notification preferences. Mem¬ 
bership structures can be mapped on standard 
Lightweight Directory Access Protocol (ldap) 15 or 
Universal Description, Directory, and Integration 
(UDDl) 16 -style models of representing organizations 
and people. In Figure 3, we show the membership 
component as being pervasive and universal across 
all the components in the platform. 

Catalog. For purchasing and sales, a catalog is an in¬ 
tegral part of the platform. The catalog in a private 
exchange should provide a unified view of the prod¬ 
ucts traded, and the mechanisms for trade, to both 
buyers and sellers. In our design, the catalog logi¬ 
cally separates the notion of items (i.e., the descrip¬ 
tion of products) and their trading positions as ex¬ 
pressed by the various parties in the marketplace. 
This concept is as follows: The product category and 
product template constitute the core catalog, and the 
trading mechanisms are linked to the catalog. The 
trades are initiated by identifying a product to be 
traded in the catalog, by selecting a trading mech¬ 
anism, and by other parameters of bids and offers 
such as quantity being traded, price, payment or ful¬ 
fillment terms, and period of validity of the trading 
position. In some special cases, such as an RFQ pro¬ 
cess, the buyer might create a new entry in the cat¬ 
alog and use the RFQ process to negotiate. 

The platform defines the categories and product tem¬ 
plates (i.e., the set of attributes for each product in 
the marketplace). Suppliers and catalog administra¬ 
tors can add their products (product descriptions) 
to the catalog by using the defined product templates. 
Suppliers are allowed to define their own product 
attributes from a dictionary provided by the platform. 
However, only catalog administrators can modify or 
add to the attribute dictionaries. Role-based access 
control on the catalog and other components is a cru¬ 
cial requirement and is part of the design, where cer¬ 


tain members can modify or create entries in the cat¬ 
alog, and certain others can only view parts of the 
catalog. 

Search and navigation. Catalog search is a crucial 
component in the B2B site. In a very large catalog 
with very many attribute types per product, a good 
search engine can provide the buyer access to prod¬ 
ucts of interest. The catalog consists of product de¬ 
scriptions, which contain a large number of at¬ 
tributes, and the attributes could have single or 
multiple values. 12 In a typical business catalog for 
private exchanges, it is very common to see millions 
of catalog entries, and each product item in the cat¬ 
alog can have anywhere between 10-40 attributes 
describing the properties of the product and the of¬ 
fering information such as price(s), quantity avail¬ 
able to promise, expected delivery time based on 
shipping location, and other relevant information. 
The platform supports a variety of search techniques 
ranging from simple text searches to more complex 
multiattribute searches, which help the buyer nar¬ 
row the number of products based on attribute val¬ 
ues. 

Request for quote. RFQs are the most common mech¬ 
anisms used for business procurement. RFQs are a 
form of reverse auction, 17 allowing the buyer to ne¬ 
gotiate price, product attributes, and terms and con¬ 
ditions, and to collaborate with suppliers on the 
specification of services and custom goods. 18-22 
Therefore, they are the preferred mechanism for ex¬ 
pensive items, custom goods, services, and direct 
goods (i.e., goods that are directly used in produc¬ 
tion). 

A buyer can initiate an RFQ to solicit quotes for a 
specific set of goods and services. These goods could 
be defined in the catalog for which the buyer wishes 
to find a better price or negotiate a long-term con¬ 
tract, or a custom good or service could be defined 
for which the buyer wishes to collaborate with the 
seller for purchasing. In our design we have consid¬ 
ered the issues of negotiation across multiple at¬ 
tributes, where the buyer can specify which product 
attributes are negotiable and which are not. 

A buyer might want to send an RFQ to specific sell¬ 
ers instead of making the RFQ public. Our design 
takes into consideration a private RFQ model, where 
the suppliers are preselected and targeted by the 
buyer, and only those selected suppliers can respond 
to the RFQ. If the RFQ is public, then every regis¬ 
tered supplier in the private exchange can respond 
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to the request. RFQs could be sealed (only the RFQ 
creator sees responses) or open (all the participants 
can see all the bids, with possibly some information, 
such as identity of the suppliers, masked). Once the 
RFQ is evaluated, winning bids can be converted into 
a single, one-time order or a contract to support re¬ 
peat purchases. 

Contracts. Most B2B transactions in the physical 
world have been driven by short- and long-term con¬ 
tracts. A contract is a document with prenegotiated 
terms and conditions between two or more busi¬ 
nesses to trade goods and services over a period of 
time. The terms and conditions include pricing, de¬ 
livery, quality, payment, credit, and discounts. Con¬ 
tracts play a very important role today in B2B trans¬ 
actions over the Internet. A majority of transactions 
in most B2B sites are mainly driven by contracts. Pri¬ 
vate exchanges, through contract mechanisms, cap¬ 
ture the existing business relationships between buy¬ 
ers and sellers. Our platform provides a mechanism 
for new contracts to be established and to renew or 
extend existing contracts. 

Auctions. The platform provides a configurable for¬ 
ward auction component. Based on our study of auc¬ 
tion methods deployed around the world, 18-26 we 
classify auctions using a few attributes or parame¬ 
ters such as interaction format, bid management pol¬ 
icies, bid to price mapping policy, and auction clos¬ 
ing rules. The implementation of the auction 
software is modularized according to these param¬ 
eters, and each of these modules can usually be con¬ 
figured independently. This allows the auction com¬ 
ponent to support hundreds of distinct auction styles. 
Auction mechanisms are crucial for primary and sec¬ 
ondary markets, as well as for sell-side private ex¬ 
changes to sell excess inventory and ascertain the 
prices in the market. Lately, reverse auctions have 
become very popular for B2B in the area of procure¬ 
ment. 

Exchanges (double auctions). There are many var¬ 
iants of the double auction or exchange mecha¬ 
nisms. 27 The different variants for exchanges are well- 
suited for different market conditions; for example, 
the continuous double auction is best if markets are 
liquid. Walrasian tatonnement can be used if it is im¬ 
portant to clear all positions and set the opening price 
in financial and commodities markets. 25 The plat¬ 
form allows different goods or commodities to be 
traded simultaneously using different exchange 
mechanisms. Furthermore, different exchange mech¬ 
anisms can be selected for a given commodity or trad¬ 


ing post based on market conditions and other ex¬ 
ternal events. Some of the financial markets open 
with a Walrasian tatonnement for establishing an 
opening market price (after the previous day’s close) 
and then switch to a continuous double auction 
(CDA) during normal trading hours. 

The double auction market has tremendous advan¬ 
tages for trading primary and secondary commod¬ 
ities over the Internet such as bandwidth, energy, and 


Different variants 

of double auctions 
are well-suited for different 
market conditions. 


agricultural products (meat, corn, wheat, and oth¬ 
ers). In some of the sell-side models, trading using 
the double-auction mechanisms provides sellers with 
a channel to get rid of excess capacity by posting of¬ 
fers and obtaining matches in real time. The ex¬ 
change does a match of the bids and offers, and or¬ 
ders are placed automatically to the sellers. The 
process can also be interrupted, and approvers could 
approve the orders before they are placed. 

In B2B private exchanges, unlike the stock and com¬ 
modities markets, the emphasis can be on multiat¬ 
tribute bids and offers. A bid can specify the price, 
quantity, quality constraints (e.g., quality > 5.0), de¬ 
livery constraints (e.g., delivery date <= June 10, 
2002), and so on. For such a bid to be matched with 
one or more offers, a matching algorithm that takes 
into account attributes and constraints is required. 
For the platform, we have developed “multiat¬ 
tribute” matching algorithms that scan the “close¬ 
ness” of the bids and offers and match them. The 
advantages are in their application to trading of com¬ 
plex commodities such as petroleum, plastics, nat¬ 
ural gas, and bandwidth, which typically contain mul¬ 
tiple attributes for trading. 

Flexible business flow. Business processes vary be¬ 
tween companies, and a B2B e-commerce platform 
has to adapt to a wide variety of business models and 
processes. In our platform, a lightweight workflow 
engine, called FlexFlow, provides this flexibility. Flex- 
Flow represents business processes as a set of state 
machines. It enhances the finite state machine model 
with some features borrowed from Unified Model- 
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ing Language (UML**) state transition diagrams. The 
business process can be restructured by simply mod¬ 
ifying the state machine and ensuring that it is valid. 

The FlexFlow engine uses the state-machine descrip¬ 
tions to directly control the execution of the busi¬ 
ness processes. It also generates controls for user in¬ 
teractions on Web pages based on the state-machine 
description. Different versions of an application can 
be generated by visually editing its FlexFlow descrip¬ 
tion, with minimal incremental effort in rewriting ap¬ 
plication software or related Web pages. FlexFlow 
thus provides an efficient way to customize the plat¬ 
form to variations in business processes and to sup¬ 
port different versions of business processes for dif¬ 
ferent sets of organizations, users, or devices in the 
same e-commerce system. 

Each process state machine has a set of states and 
a set of transitions between the states. States are sym¬ 
bolic representations of the condition of a business 
object such as an RFQ or a quote for an RFQ. Tran¬ 
sitions are a tuple of ( action , role). An action cor¬ 
responds to an atomic transaction, implemented as 
a command in the WebSphere Commerce Suite ap¬ 
plication framework. Role corresponds to the role 
of the party issuing the command, such as buyer, 
seller, or system. 

When an event occurs in the context of a business 
process, FlexFlow uses the process state machine to 
start the appropriate action. An event can be a user 
action such as pressing a button on a Web form, a 
message from an external system, an event from an 
internal component such as the scheduler, or a co¬ 
ordination message from another business process. 
The FlexFlow engine checks whether in the given 
state of the process, the action corresponding to the 
event can be taken by the role of the originator of 
the event. If so, it executes the action and updates 
the state of the process; otherwise, it throws an ex¬ 
ception. Once the action is correctly executed, the 
FlexFlow system informs the user interface of the 
next set of valid actions for that user’s role, and this 
information is used to dynamically generate controls 
on the user interface. If the action fails, FlexFlow 
rolls back the state of the process. 

Marketplace Edition and Business Edition 

WebSphere Commerce Suite, Marketplace Edition 
(mpe) 28 was designed to provide a platform for pri¬ 
vate exchanges and public marketplaces in various 
industries. The WebSphere Commerce Business Edi¬ 


tion (be) is geared toward B2B sell-side operation. 
In this section we outline some of the differences in 
the two platforms and our experiences with deploy¬ 
ing MPE. 

In BE, buying is the only function provided to end 
users; the setup of sales or trade mechanisms is a 
complex process targeted for the sell-side site ad¬ 
ministrators. In marketplaces, end users are busi¬ 
nesses that wish to buy or sell. MPE provides sym¬ 
metric processes for all parties in a trade; for 
example, in MPE, the process for buying an item from 
the catalog has a corresponding similar process for 
offering an item for sale, and the process for request¬ 
ing quotes for a purchase has a corresponding pro¬ 
cess for offering to sell. Order management in BE is 
much richer in function than in MPE. It provides or¬ 
der capture, order status, order cancel, repeat or¬ 
ders, order reject, back order, and a variety of func¬ 
tions such as analysis tools and collaboration tools, 
crucial for B2B transactions. 

MPE uses a symmetric model of the catalog, where 
product descriptions defined by the catalog admin¬ 
istrator are maintained. Both sellers and buyers could 
access the catalog and create requirements on what 
to buy and what to sell. Sellers can post offerings 
based on the product descriptions to the catalog and 
select the trading mechanism of choice. Likewise, 
buyers can post requirements in the catalog in the 
form of an RFQ, and also create contracts on one or 
more items in the catalog. In BE, the catalog does 
not aggregate products from multiple suppliers but 
separates them by stores. 

BE supports a notion of a package, which is a col¬ 
lection of items that have an SKU, or stock keeping 
unit (the product identification), and packages are 
bought as a whole. It also supports a bundle, where 
the catalog items are loosely coupled, and buyers can 
place orders on one or more items in the bundle. 
These features are not supported in MPE. In both 
platforms, a parametric search is offered to buyers 
to narrow the number of catalog items of interest. 
This advanced search feature is based on ranking cat¬ 
alog items on attributes and value ranges. 

Businesses use a variety of mechanisms to buy, sell, 
and trade goods and services. MPE supports most 
classes of these trading mechanisms. They include 
fixed price, contracted price, auctions, RFQs, reverse 
auctions, and exchanges. In BE, the trading mech¬ 
anisms are restricted to the following: fixed-price and 
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contract buying from the catalog, forward auctions, 
and single-supplier RFQs. 

A novel distinguishing 29 feature of MPE has been the 
exchange component, which is a double-auction 
mechanism for trading commodities or any well-de¬ 
fined goods and services. The design was based on 


E-marketplaces 
support nearly all types 

of B2B transactions. 


trading-post concepts from financial markets. The 
concepts were extended further to allow multiple 
matching and pricing algorithms to run simulta¬ 
neously and support thousands of transactions simul¬ 
taneously on the system. 30 For example, a private 
exchange for energy products could use the enhanced 
trading-post concept by trading oil on a different 
trading post from trading power or trading natural 
gas. Each trading post 31 is configured with a differ¬ 
ent pricing and matching algorithm and could also 
be run physically on a different machine, thereby sup¬ 
porting scalability and speed. 

In MPE, contracts are just one of the trading mech¬ 
anisms enabled to determine prices, whereas in BE 
contracts play a central role in the architecture and 
operation. A contract has a number of terms and con¬ 
ditions that control the buyer’s interactions and trans¬ 
actions with the seller. They govern the look and feel 
of doing business, the items in the catalog that the 
buyer can view, the prices that are shown, the ship¬ 
ping mechanism used, and the returns policy en¬ 
forced. In MPE, contracts can be negotiated on line 
for one or more products or product categories, and 
any number of contracts can be established between 
buying organizations and selling organizations. 

Experience with MPE. E-marketplaces support 
nearly all major types of B2B transactions, such as 
sales via catalogs, contracts, and auctions, procure¬ 
ment via reverse auctions and RFQs, and trading via 
exchanges. Therefore, a platform, such as MPE, that 
is made for public marketplaces can also be easily 
deployed for private exchanges, sell-side, and pro¬ 
curement. Our customers used MPE to create public 
and private marketplaces, sell-side and procurement 
sites, exchanges, and other variations on these. The 


companies included both established “brick and mor¬ 
tar” industries and “dotcom” startups. 

Many dotcom startup customers tried to capitalize 
on the perceived novel potential of e-marketplaces 
to launch new businesses. The investment money 
available for dotcom businesses was drastically re¬ 
duced in 2001. The problem was compounded by lim¬ 
ited acceptance of open public marketplaces by 
suppliers. However, the technology for public mar¬ 
ketplaces is also useful for private exchanges. Thus, 
many of these customers were able to switch from 
being marketplace owners to supplying private ex¬ 
change and other B2B services to traditional busi¬ 
nesses, while still being based on MPE. MPE has been 
deployed on single-tier and multitier configurations. 
The multitier configuration supports load-balancing 
of requests among the MPE servers running on mul¬ 
tiple hardware nodes. Load-balancing is crucial for 
businesses running the private exchange in order to 
provide reasonable response times for the partici¬ 
pants along with reliability. 

The difference between public and private exchanges 
brought other challenges as well. Public marketplaces 
run by dotcom companies often had no existing in¬ 
frastructure. Very little integration was required 
since no legacy order management or fulfillment sys¬ 
tems existed. In contrast, private trading exchanges 
are usually run by mature companies with existing 
infrastructure. This requires the B2B platform to be 
offered on an expanded set of operating system and 
database platforms. It also requires better integra¬ 
tion with existing customer systems and internal e- 
business systems (back-end systems). Integration can 
be in the form of a more robust set of messages to 
both front-end buy-side tools from procurement 
companies as well as messages for existing back-end 
systems for ERP. Thus, to meet these requirements 
better, BE has support for multiple hardware and op¬ 
erating systems and different databases. It also pro¬ 
vides strong connectivity solutions. 

Summary 

We presented the architecture of a platform for B2B 
private exchanges and seller sites (sell-side) that sup¬ 
port a wide variety of business functions such as 
membership, role-based access control, catalog, cat¬ 
alog search, purchasing, contracts, trading mecha¬ 
nisms for negotiation and price-discovery, order 
placement, and order-status tracking. We proposed 
a collection of core components for fostering bus¬ 
iness interactions and collaborations. Most of the 
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components described in the platform were incor¬ 
porated into two IBM products, MPE and BE, in or¬ 
der to address the requirements for private ex¬ 
changes and seller models of e-business. MPE has 
been deployed at many sites and is currently being 
used for private and public marketplaces over the 
Internet. We have gathered sufficient experience 
from the deployments and a good understanding of 
the critical business needs. We plan to use the expe¬ 
rience we gained to design the next generation of 
B2B platforms with advanced business intelligence 
and collaboration tools. 

* ‘Trademark or registered trademark of the Object Management 
Group. 
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